异步社区会员 /db 冷锋(18823840827) 专享尊重版权

版权信息

Hacking the Game——我的“孔颜乐处” 开放源码是开源软件

吗？

Ten Rules for Open Source Success 开源项目成功的十条准则（修订

版）

如何更有效地学习开源项目的代码如何看待开源社

（kaiyuanshe）

成功的开源软件都有什么样的特点

Source Code + X

三代开源社区的协作模式聊聊 Github 的方法

与哲学降低门槛与质量控制

黑客的胜利——读《增长黑客》有感

Free Software vs. Open Source

如何看待陈皓在微博上对闭源和开源软件的评论为什么

GitHub 只能关注个人，而不能关注组织

28 万个开源项目之番外篇从 28 万个开源项目中，我们

能够学到一些什么基于包管理工具的开源生态圈企业开

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

源杂谈如何提高阅读源代码的能力当谈开源时，我谈些

什么

开源不是石头汤

OpenSSL 是否值得同情？

开源项目也要讲注意力经济

“我们的开源项目”活动发起人——庄表伟专访我们都是

干柴，期待烈火！

拥抱开源，从中受益

GitCafe 这样的代码托管网站在国内的前景如何？外国

大牛也不过如此——《梦断代码》读后感应该不遗余力

的打击劣质开源

我能为开源做些什么？

Java 社群该向 Ruby on Rails 学习些什么？欢迎来到异

步社区！

版权信息

书名：开源思索集

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不

得以任何方式复制和传播本书内容。

我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识

产权。

如果购买者有侵权行为，我们可能对该用户实施包括但不限于关

闭该帐号等维权措施，并可能追究法律责任。

Hacking the Game——我的“孔颜乐处”

不合格的儒家信徒

大约在 10 多年前，那时候我成天泡在网易的宗教信仰版，在与

很多不同宗教信仰的朋友讨论的过程中，我也逐渐有了自己清晰的三

观，以及较为确定的信仰，于是我写了一篇《我的信仰地图》。自己

写了这么一篇文章，当然是挺得意的，后来有了一个机会，我还把这

篇文章发给了自己的大学哲学老师，内心其实是希望获得他的表扬

的。在文章中，我对于儒家的看法是这样的：

在儒家，个人问题几乎是完全不被考虑的，社会、他人、国

家、天下才是真正重要的。

正心、诚意是为了修身，而修身是为了齐家、治国、平天下。

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

对自己下功夫，并不是为了自己，而是为了比自己更加广大

的，更加重要的事情。

儒家从来就不告诉你：“信了我的教，你能如何如何”。

我的选择，最终还是儒家信仰，有很多可以说的理由，而最大

的理由，就是因为这种信仰不是为了自己。有很多名人名言深深地

打动了我，例如：“先天下之忧而忧，后天下之乐而乐”“为国为

民，侠之大者”......

顾老师对于我的文章，并未做太多的评价，却问我：“你有没有

想过，孔子与颜回的快乐，是从何而来？”

于是，当场我就懵了。事实上，我并未真正思考过这个问题，而

作为一个儒家信徒，缺乏对这层境界的思考与感悟，可以说就是不合

格的！

计算机的精彩世界

我虽然一直对哲学很感兴趣，但是早在小学五年级的时候，我就

已经把计算机作为自己的终生爱好了。能够操作计算机，就意味着一

个全新的世界，完全在我的掌控之中。只要我能够编出足够好的程

序，那个世界里的一切，都会如我所愿地运行起来。

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

大概在初三的时候，父母终于帮我买了一台中华学习机。我开始

废寝忘食地投入了所有的业余时间，开始研究。找到一切当时能够找

到的代码，敲入电脑、运行，然后查看效果。

那时候的程序，其实非常简单，字符界面，BASIC 语言，还有些

神奇的一行代码之类。现在看来，当时真是容易满足，看到屏幕上打

出一行文字，画出一个五角星，或者从喇叭里发出一些音乐旋律，我

就能从中获得极大的乐趣。当然，在追寻这些乐趣的时候，我并无伦

理或者信仰上的自觉。

直到，我读到了“黑客伦理”。

黑客伦理

有一本书，在我的读书生涯中举足轻重，也许对于很多人来说，

都是如此。据说，这本书让 John Carmack（《 Doom》《 Quake》的创造

者，游戏软件天才）产生了极大的共鸣，给予了它在游戏领域前行的

动力。这本书名叫《黑客——计算机革命的英雄》。

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

我的朋友@dreamhead 对本书的评价是：“那是一部波澜壮阔的黑客

史，那是一群发自内心喜欢计算机的人对技术最简单、最纯粹的热

爱，那是一种超凡的魅力。如果真心热爱计算机，你会发现，其实你

并不孤单。”

在这本书的第 1 章里，作者记录了黑客伦理最早的版本：

对于计算机的访问（以及任何可能帮助你认识我们这个世界的事

物）应该是不受限制的、完全的。任何人都有动手尝试的权利！

所有的信息都应该可以自由获取。

不迷信权威——促进分权。

评判黑客的标准应该是他们的技术，而不是那些没有实际用途的

指标，比如学位、年龄、种族或职位。

你可以在计算机上创造出艺术与美。

计算机可以让你的生活更加美好。

以上的每一条都是我 100%接受并愿意信奉的信条。因此，之前

在 360 的开源大会上，我也做了一次演讲：《 Hacking the Game——聊

聊黑客的三观》。在这个演讲中，我对于自己的信仰，做了再一次的

梳理。

黑客的世界观、人生观与价值观

一、黑客的世界观

这个世界，是可以被认识的

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

所以，探索世界，是一件有趣的事情。

找到巧妙的方法，探索世界，是一种享受。

这个世界，并不完美

找到漏洞，是一种乐趣。

让世界变得更加完美，是一件更有趣的事情。

二、黑客的人生观

世界是一个游乐场，人生是一场大游戏

赢得游戏很重要。

玩得开心、玩出精彩，更加重要。

游戏要大家一起玩才开心

和会玩的人一起玩。

游戏规则一定要公平、公正、公开。

三、黑客的价值观

Happy Hacking & Just for Fun：有乐趣，才是最高的价值。

Freedom：自由是必不可少的价值。

Fair Play：若无公平，则一切皆休。

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

Better world, Better life：让世界变得更好，才能体现黑客的价

值。

以上这些，其实只是上次演讲的提纲，本来我是打算把那个演讲

的内容文字化写下来，就作为这篇文章的主干，但是：“这种视频转

文字的活实在是太无趣了，大家有兴趣的自己看视频去吧！”

信仰的融合

在演讲的最后一页，我事实上修正了自己对于儒家的观点，也可以

说，我终于回答了多年以前顾老师对我的发问：“孔颜乐处，乐在何

处？”

在西方宗教传统中，有一个著名的论点：上帝让好人成为好人，

就是对他们最大的奖赏！

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

这个观点应用于黑客伦理之中，也可以这样表述：上帝让黑客自

得其乐，就是对他们最大的奖赏。

而对于我这样的黑客型儒家信徒而言：成为一个黑客，并乐在其

中，这就是我的“孔颜乐处”！

开放源码是开源软件吗？

开放源码和开源软件的不同是什么？

开放源码不能叫做开源软件吗？

所谓开源，仅仅是指符合 OSI 定义的 Open Source 吗?

Open Source 的来历

1997 年，埃里克·雷蒙（Eric Raymond）出版其著作《大教堂和

市集》，探讨黑客社区与自由软件原则。1998 年初，该论文受到极大

的关注，成为促成网景通讯公司将其受欢迎的互联网套装软件《网景

通讯家》（Netscape Communicator）释放成为自由软件的因素之一。

这些代码即为今日大家熟悉的 Mozilla Firefox 与 Thunderbird。

网景的行动激起雷蒙及其伙伴深入研究如何将自由软件基金会的

自由软件概念及优点带入商业软件产业。他们查觉基金会的社会活动

不如网景等公司的行动来得吸引人，因而试图重新包装自由软件运动，

以强调分享与协作软件源代码的潜在商机。他们选用的新名称为“开

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

放源代码”（open source），很快地布鲁斯·佩伦斯（Bruce Perens）、出

版家提姆·奥莱理（Tim O'Reilly）、林纳斯·托瓦兹

（Linus Torvalds）及其他人支持这个新名称。开放源代码促进会于

1998 年 2 月创建，以推动使用新名称，并宣扬开放源代码的原则。

注：以上介绍来源于中文维基百科《开源软件》词条。

OSI 对开源的定义

开放源代码由 Bruce Perens（Debian 的创始人之一）定义如下。

自由再散布（Free Distribution）：允许获得源代码的人可自由再将

此源代码散布。

源代码（Source Code）：程序的可执行文件在散布时，必须以随附

完整源代码或是可让人方便的事后获取源代码的形式。

派生著作（Derived Works）：让人可依此源代码修改后，再依照同

一许可协议的情形下再散布。

原创作者程序源代码的完整性（Integrity of The Author’s Source

Code）：意即修改后的版本，须以不同的版本号码以与原始的代

码做分别，保障原始的代码完整性。

不得对任何人或团体有差别待遇（No Discrimination Against

Persons or Groups）：开放源代码软件不得因性别、团体、国家、

族群等设置限制，但若是因为法律规定的情形则为例外

（如：美国政府限制高加密软件的出口）。

对程序在任何领域内的利用不得有差别待遇（No Discrimination

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

Against Fields of Endeavor）：意即不得限制商业使用。

散布许可协议（Distribution of License）：若软件再散布，必须以

同一条款散布之。

许可协议不得专属于特定产品（License Must Not Be Specific to a

Product）：若多个程序组合成一套软件，则当某一开放源代码的

程序单独散布时，也必须要匹配开放源代码的条件。

许可协议不得限制其他软件（License Must Not Restrict Other

Software）：当某一开放源代码软件与其他非开放源代码软件一

起散布时（例如放在同一光盘），不得限制其他软件的授权条

件，也要遵照开放源代码的授权。

许可协议必须技术中立（License Must Be Technology-Neutral）：意

即许可协议不得限制为电子格式才有效，若是纸本的许可协议也

应视为有效。

注：以上介绍同样来源于中文维基百科《开源软件》词条。

从词语分析的角度，讨论“access to the source

code”、“open-source”、“开放源代码”、“开源”

在 OSI 的开源定义的文本中，开宗明义的第一句话就是：“Open

source doesn't just mean access to the source code. ”甚至在后面的文字

里，直接将 open-source 连接起来，表示这是一个词，而不是两个词

组成的词组。

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

所以，与此类似的，在中文里，我们可以认为：“开放源代码”是

一个动词+一个名词。而“开源”则是一个特定的词汇。作为动词，我

们说将某某软件开源，是一种行为。作为形容词，我们称某某软件是

一个开源(的)软件，不仅仅是指我们能够获取到它的源代码。

从严格意义上来说：当我们判断某某软件是否开源时，首先需要

检查的，是它的授权协议，是否符合 OSI 对于开源的定义。最好，它

的授权协议已经获得 OSI 的认证，我们就不必仔细去分析它的条款

了。

但是，如果我们看到一个软件，不含任何授权协议的文本，我们

可以确定：“这只是一堆代码，虽然我可以获得代码，但是不是可以

任意使用，都无法明确。更不要说算是开源软件了。”

为什么开放源代码，还需要有一个授权协议

当我将自己的源代码放到某个地方，供人公开下载。接下来会发

生什么事情？如果我是一个老手，由于见多识广，我会估计到，也许

会发生很多不同的事情。有些事情，我乐于见到。比如某人给我发邮

件，提交 bug 或者 patch。有些事情，我无所谓（或者也没办法干

涉），比如某人在自己家里修改了代码，然后自己使用。有些事情，

我认为侵犯了自己的权益，比如别人拿了我的代码，却号称是自己开

发的，并且删除了所有能够证明是我的劳动的证据。还有些事情，我

也很在意，比如：虽然没有侵犯我的权益，却潜在的侵害了这个软件

的用户的权益等。

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

总之，当一个项目的源代码被公开，哪些事情，我希望发生。哪

些事情，我不希望发生。这就需要在一个协议里，被明确的规定下来。

如果发布源代码的人，对此毫不在意，甚至由于“根本没仔细思

考过会发生什么”，那么我们会认为，这样的“开源”，的确是不够认

真。在我曾经翻译的一篇《开源项目成功的十条准则》里，第二条

就明确写到：“以相同方式共享”是开源的安全带。在遇到严重的事

故之前，你大可吹嘘自己完全不需要它。一旦出现事故，你就会发

现自己满脸污垢，或者“轻微擦伤”，不要成为一个“伤员”。使用“以

相同方式共享”的许可证吧，如果你觉得 GPL/LGPL 太过于政治化，

那就用

MPLv2。

老司机的教训，要认真地听啊！

太过于政治化的许可证，是怎么回事

在开源（Open Source）之前，其实还有一个重要的先驱，自由

软件（Free Software），在自由软件的定义中，维护软件用户的自由是

正义的，限制（剥夺）软件用户的自由是非正义的。

自由软件用户的四项自由是指：

自由度 0：无论用户出于何种目的，必须按照用户意愿，随时随

处自由地运行该软件。

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

自由度 1：用户可以自由地学习并修改该软件，以此来帮助用户

完成自己的计算。作为前提，用户必须可以访问到该软件的源代

码。

自由度 2：用户可以自由地分发该软件的拷贝。

自由度 3：用户可以自由地分发该软件修改后的拷贝。借此，用

户可以把改进后的软件分享给整个社区，令他人也从中受益。作

为前提，用户必须可以访问到该软件的源代码。正如自由软件的

官方文档中所说的：一个软件只有提供了以上所有的自由给它的

用户，才可以被成为自由软件。否则，它就是非自由的。尽管我

们也可以比较非自由软件为其用户提供的自由度，但是我们认

为，无论如何，非自由软件本身是不道德的。

是的，自由软件的核心，在于其包含严厉的道德判断。事实上，

在绝对的软件用户的自由背后，开发者的自由，被道德绑架了。

再引用一段：“无论在哪种情况下，只有所有用户使用的代码都

满足了这四项基本自由，该程序才能被视作自由软件。例如，有两个

程序，甲程序运行的时候会自动调用乙程序。发布甲程序意味着用户

必须使用到乙程序，那么必须甲乙两个程序都是自由的，甲程序才是

自由的。如果通过修改甲程序，使其不再依赖乙程序，那么仅仅以自

由软件的形式发布甲程序即可”。

相比之下，开源软件的相关定义是：“许可协议不得限制其他软

件（License Must Not Restrict Other Software）：当某一开放源代码软

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

件与其他非开放源代码软件一起散布时（例如放在同一光盘），不得

限制其他软件的授权条件，同时也要遵照开放源代码的授权”。

仔细的阅读开源软件的定义，我们就能发现，较之自由软件，

“开源”是道德中立的。虽然 RMS 非常痛恨这样的行为，但是我们应

该承认，更加宽松的、非道德化的开源标准，有助于开发出更多、更

好的软件。

然而，开源同样被罩上了道德的光环

开源（open-source）是一个好词，虽然没有像自由软件（free

software）那样标榜自己的道德属性，但这同样是一个好词。开源是

一种值得赞赏的行为，虽然因为开源，企业最终能够赚得更多，但是

在开源的那一刻，企业是放弃了一部分潜在利益的。

至于个人的开源，大多数是无利可图的，也就更加值得钦佩了。

在这种情况下，不仅仅是社会上对于开源有诸多褒扬，一旦企业

决定开源，肯定会加入到歌颂开源，标榜&自我标榜的行列之中。既

然都已经放弃了一部分潜在的“利”，当然得在“名”上面努力的赚回来

呀。

于是，整个 IT 圈子里，会有这种一种氛围：只要一个企业愿意

开源，就值得称赞。而且，企业开源，也成为这个企业变得更加开

放、更加“尊重社区”的象征。更进一步地，如果大家发现，这个企业

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

并非真正开源，只不过赚了名声，却完全没有牺牲利益时，一种感情

受到伤害的心情油然而生。

对“伪开源”的道德谴责，也由此而生。

企业开源，不是一种道德行为，而应该是一种商业

行为

我们曾经听过一句话：“免费的其实是最贵的”。同样的理由：

“当一家企业跟你谈情怀，最终还是想赚你的钱”。所以，如果一家企

业声称自己的“开源”或者“赞助开源”，完全不是为了自己的商业利

益。我反正是不信的。

相反，我宁愿一家企业，真的理解了以开源为基础的商业模式，

并且通过成熟、有效运作，借助商业赚取了更多的利益。这种光明正

大的赚钱，值得所有人敬佩。包括商业眼光、技术实力与市场手段！

假设真的有企业家，出于情怀而开源。我倒是会内心充满疑虑。

这种事情，他们家真的想明白了？真的能持久？他们的开源软件，真

的能够放心使用？

开发者（尤其是企业）可以选择任何一种协议开源

如果我们不但承认用户的自由，也承认开发者的自由。如果我们

不但支持用户的利益，也支持开发者的利益。如果我们承认不同的软

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

件，面对着不同的技术与市场状况。如果我们承认，应该尊重开发者

对于自身利弊的判断。

那么，开发者（尤其是企业）选择以何种协议开源，是首先应该

被尊重的自由。无论他选择 GPL、Apache License 还是 MIT 中的任何

一种，都不会比选择其他协议，更加道德，或者更加不道德。更明确

的表达是：并不是一个企业牺牲得越多，就越道德，反之亦然。

更进一步，如果他选择的不是任何一种已有的开源协议，而是自

行草拟了一份协议。并以此来捍卫自己特别重视的利益。这也同样无

可厚非，无可指责。因此，当我们声称：某某软件并不是符合 OSI 定

义范畴的开源软

件。也仅仅是一种事实陈述，而非道德谴责。

是否存在 OSI 定义之外的开源软件

这是一个很有趣的话题，我们可以以非常学究的方式来分析，也

可以以较为轻松愉快的方式来研究一下。在写这篇文章的时候，我发

现了两种许可协议，都非常有趣。

WTFPL（Do What The Fuck You Want To Public License，中文

译名：你他妈的想干嘛就干嘛公共许可证）

大概意思是：你他妈的想干嘛就干嘛，以及，如果你改了这个协

议，请不要再用这个名字。来源介绍

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

还有一种协议，叫做 BEER-WARE LICENSE，你可以使用此软

件做任何事。如果我们在某一天相遇了，而且你认为此软件很有价

值，你可以为我买一瓶啤酒来答谢。来源介绍

这两种协议，看上去都非常乱来。更加有趣的是：它们都经过了

FSF（自由软件基金会）的认证，确认它们是兼容 GPL 的自由软件许

可证。

但是，它们却没有获得 OSI 的认证。因此，按照 OSI 的定义，如

果有软件使用了这样的许可证，是不能称之为开源软件的。

因此，泛泛而论：我们可以认为存在狭义的（符合 OSI 定义

的）开源软件，与广义的开源软件。

但是：我没办法准确的定义“广义的开源软件”。因为太难了！

有中国特色的开源

当开源软件进入中国，当中国的个人与企业也开始参与开源，甚

至发起开源项目的时候，事情变得更加复杂了。

先说说法律问题：在中国，目前“貌似能够”保护开源软件的，是

两部法律：《著作权法》与《计算机软件保护条例》，但是在这两部法

律中，都没有明确的开源软件的定义。而且，在《计算机软件保护条

例》中，还认为“同一计算机程序的源程序和目标程序为同一作品。”

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

但是，发布目标程序与同时发布源程序，明显是两种差异巨大的行

为。

在软件著作权人依法享有的权力中，虽然包含修改权。但是，如

果在发行或网络传播的时候，不提供源程序，事实上是无法转让或授

予他人修改权的。（非编译型的脚本语言，混淆以后的源代码，又是

两种需要分析的特殊情况）

再者，“保护条例”中所说的：“软件著作权人可以全部或者部分

转让其软件著作权，并有权获得报酬”，其中的部分转让，是否包含

“修改权的部分转让”？例如，虽然允许修改源代码，但是代码中关于

许可证的注释内容，能不能被删除或修改？还有就是外国开源软件，

包括开源软件的许可协议，是否受到中国法律保护的问题。更进一

步，直接采用国外开源软件的常用许可协议的国产开源软件，是否也

能受到中国法律的保护呢？

在我看到的网上的一些分析认为：“将软件开源只是作者处置自

己版权的一种方式，其附带的开源协议只要不与其他法律相违背，当

然是合法有效的。开发者将软件源代码发布并附带开源协议的行为，

就是向不特定多数的人作出一个附条件的意思表示，任何人只要使用

该软件，就应当理解为使用的行为接受了这样的意思表示，即作者和

使用者之间建立了软件授权使用合同，而开源协议中所约定的条款也

就成为了这个授权合同的一部分，使用者应当在该合同项下履行自己

的义务”。参考链接

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

但是，真正令人困扰的，是一旦侵权行为发生，如何判断？如何

寻找证据？是不是开源软件的作者还需要先去做“著作权登记”？国内

虽然的确有一些学术上的研究，但是因为整个法制不够健全，而且也

尚未出现“开源相关的真实案件”，因此在执行上还是空白。

在这种现实情况下，一个中国企业选择开源，的确是要冒着“被

侵权之后求告无门”的风险的！在放出自己的源代码时，选择更加严

格的措辞，更加严格的授权，甚至明明是开源，也先写一句“保留所

有权利”，也就可以理解了。

正面回答问题

关于文章开头提出的问题，我的回答如下： 1．从严格意义上来

说：开源软件是一个专有名词，特指选择了符合 OSI 定义的授权

协议的软件。

2．另外还有大量的未选择明确的授权协议，或者自行拟定开源

授权协议，并开放源代码的软件，同样也是广义的开源生态圈的一部

分。

3．在国内的法律环境对于开源软件的保护逐步健全起来之前，

盲目要求个人或企业，严格按照 OSI 的定义开源，甚至严格按照 FSF

的定义开源，并不妥当。以是否道德来绑架，更不应该！

4．无论当前的法制环境如何，选择经过反复锤炼的、成熟的开

源协议，其实是对自身开源行为更加审慎的态度。（如果它保护不了

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

你，你的条款再严格，它也保护不了。但是，如果你自己发明的条款

有漏洞，国家法制就算再健全也帮不了你。）

5．将开源与道德脱钩，既不以道德相标榜，也不以道德相指

责。这是对于开源软件，最好的态度！

Ten Rules for Open Source Success

开源项目成功的十条准则（修订版）

Everyone wants it, lots of people try it, yet doing it is mostly painful

and irritating. I’m speaking about free software aka open source. Today

I’m going to summarize 30 years of coding experience in ten management-

proof bullet points.

每个人都想去做，也有很多人跃跃欲试，但是真做起来却常常会

令人痛苦和愤怒——我说的是自由软件，或者更宽泛一些的开源软

件。今天我要将自己 30 年来的开发经验，总结为开源软件的十条成

功法则。

1．People Before Code（人比代码重要）

This is the Golden Rule, taught to me by Isabel Drost-Fromm. Build

community, not software. Without community your code will solve the

wrong problems. It will be abandoned, ignored, and will die. Collect

people and give them space to work together. Give them good challenges.

Stop writing code yourself.

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

这是一条黄金法则，是 Isabel Drost-Fromm（Isabel

DrostFromm 是 Apache 软件基金会的成员，Apache Mahout 的创立

者之

一）教给我的。我们要建立的是社区而不是软件。没有社区，你的代

码就会用来解决错误的问题。然后这些代码会被抛弃、忽略，最后死

去。正确的做法是把人集结起来，给他们协同工作的空间，给他们充

分的挑战。切记不要亲手来写代码！

2．Use a Share-Alike License（使用“以相同方式共享”的许可证）

Share-alike is the seat belt of open source. You can boast about how

you don’t need it, until you have a bad accident. Then you will either find

your face smeared on the wall, or have light bruising. Don’t become a

smear. Use share-alike. If GPL/LGPL is too political for you, use MPLv2.

“以相同方式共享”是开源的安全带。在遇到严重的事故之前，你

大可吹嘘自己完全不需要它。一旦出现事故，你就会发现自己满脸污

垢，或者‘轻微擦伤’，不要成为一个“伤员”。使用“以相同方式共享”

的许可证吧，如果你觉得 GPL/LGPL 太过于政治化，那就用

MPLv2。

3．Use an Zero-Consensus Process（使用一个无需达成共识的协作

流程）

Seeking upfront consensus is like waiting for the ideal life partner. It

is kind of crazy. Github killed upfront consensus with their fork/pull-

request flow, so you’ve no excuse in 2015. Accept patches like Wikipedia

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

accepts edits. Merge first, fix later, and discuss out of band. Do all work on

master.

Don’t make people wait. You’ll get consensus, after the fact.

寻求事前的共识就像是在等待理想的人生伴侣，这简直就是疯

狂。借助 fork/pull-request 这种模式，Github 已经干掉了事前共

识，所以在 2015 年的今天你没有任何借口坚持事前共识。你应当像

维基百科那样接受修改。先合并，再修复，同时单独讨论。所有工作

应当在 master 分支上进行，不应当让大家等待。有了既成事实，共

识会随之而来。

4．Problem, then Solution（首先是问题，然后才是解决方案）

Educate yourself and others to focus on problems not features. Every

patch must be a minimal solution to a solid problem. Embrace experiments

and wild ideas. Help people to not blow up the lab. Collect good solutions

and throw away the bad ones. Embrace failure, at all levels. It is a

necessary part of the learning process.

教育自己和其他人，聚焦于问题而非功能特性。每一个补丁都必

须是解决某个实际问题的最小化的解决方案。你需要勇于尝试，勇于

接受疯狂的想法。你还需要帮助他人，确保他们干的事情不会导致实

验室的爆炸。收集好的解决方案，抛弃那些糟糕的方案。在各个层面

上都应当宽容失败。这是学习过程中不可缺少的一部分。

5．Contracts Before Internals（首先约定，然后再完成内部实现）

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

Be aggressive about documenting contracts (APIs and protocols) and

testing them. Use CI testing on all public contracts. Code coverage is

irrelevant. Code documentation is irrelevant. All that matters is what

contracts the code implements, and how well it does that. 要积极地记录

约定（API 与协议）并加以测试。要使用持续集成工具测试所有的公

开约定。代码覆盖率是无关紧要的，代码文档也是无关紧要的。真正

重要的是代码实现了哪些约定，以及它们是如何实现的。

6．Promote From Within（从内部提拔）

Promote contributors to maintainers, and maintainers to owners. Do

this smoothly, easily, and without fear. Keep final authority to ban bad actors.

Encourage people to start their own projects, especially to build on, or

compete, with existing projects. Remove power from people who are not

earning it on a daily basis.

将贡献者提拔为维护者，将维护者提拔为负责人。以流畅、

轻松且无畏地方式来做。保留干掉‘害群之马’的最终权力。鼓励大家

开始自己的项目，尤其是基于已有项目，或者与已有项目竞争的项

目。每天持之以恒地检视并剥夺那些不再贡献者的权力。

7．Write Down the Rules（将规则写下来）

As you develop your rules, write them down so people can learn them.

Actually, don’t even bother. Just use the C4.1 rules we already designed for

ZeroMQ, and simplify them if you want to.

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

当你制定规则时，请将他们写下来，以便人们可以了解它

们。事实上，你甚至都不需要亲自动手——如果你愿意，可以直接套

用我们为 ZeroMQ 制定的规则 C4.1，再按需简化。 8．Enforce the

Rules Fairly（公平地执行规则）

Use your power to enforce rules, not bully others into your “vision”

of the project’s direction. Above all, obey the rules yourself. Nothing is

worse than a clique of maintainers who act special while blocking patches

because “they don’t like them.” OK, that’s exaggeration. Many things are

much worse. Still, the clique thing will harm a project.

用你的权力去执行规则，但不要强迫别人认同你对于项目发展方

向的“愿景”。最要紧的是，你自己必须遵守规则。最糟糕的事情莫过

于维护者自己形成了小圈子，仅仅因为“不喜欢”就拒绝其他人的补

丁。好吧，这样说有点夸张了。不过，很多情况其实更加糟糕。还是

那句话，小圈子对项目是有害的。

9．Aim For the Cloud（以“云”为目标）

Aim for a cloud of small, independent, self-organizing, competing

projects. Be intolerant of large projects. By “large” I mean a project that has

more than 2-3 core minds working on it. Don’t use fancy dependencies like

submodules. Let people pick and choose the projects they want to put

together. It’s economics 101.

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

以小型的、独立的、自组织的、竞争性的（一群可以自由协作

的）项目为目标，（市场）不能容忍大项目。所谓“大”，我的意思是

一个项目包含了 2~3 个核心想法。要拒绝子模组那样花哨的依赖关

系。让大家去挑选，并将他们选择的项目放到一起（工作）。这是经

济学的常识。

10．Be Happy and Pleasant（开心愉快最重要）

Maybe you noticed that “be innovative” isn’t anywhere on my list.

It’s probably point 11 or 12. Anyhow, cultivate a positive and pleasant

mood in your community. There are no stupid questions. There are no

stupid people.

There are a few bad actors, who mostly stay away when the rules are clear.

And everyone else is valuable and welcome like a guest who has traveled

far to see us.

也许你注意到了，“创新”并不在我的建议列表中。它很可能排在

第 11 或 12 点。总之，你需要在你的社区里培养一种积极的、愉快的

氛围。愚蠢的问题，愚蠢的人都应当被踢出去。就算有“老鼠屎”，也

会在清楚的规范下自动消失。剩下的人是则有价值的，我们欢迎有朋

自远方来。

ps. 在诸多朋友的帮助下，对此准则做了修订，其中有了不少自

己的思考，仅仅是在译文之中有了体现，没有一一说明，请读者朋友

见谅。详细的修订比对记录，详见我的博客

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

http://www.zhuangbiaowei.com/blog/?p=2035。因为实在琐碎，就不再

这里罗列了。

如何更有效地学习开源项目的代码

说说我的开源学习经历：

1．下载源代码之后，首先要跑起来。编译通过、正常运行。

2．在你觉得最有可能的运行到的地方，设置断点或者抛出异

常，这样，就能够找到一个项目在正常运行时的入口点。

3．从入口点所在的那个源文件开始阅读，逐步把握整个项目是

如何启动起来的。

4．随便改点代码，看看会不会报错，如果报错，会从哪里报

错。

5．试着把报错屏蔽、修复、或者绕开。

6．尝试理解一个系统的内部结构，多少组成部分，主线模块是

哪些？辅助模块是哪些？

7．从实际需要出发，修改这个项目，满足自己的某一个小的需

求。

在此之前，尽量不要在网络上找答案。

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

8．看看相关的讨论与心得，看看是否与自己的理解相一致。

9．提交 bug fix 或者某个新的功能代码。

在学习开源的过程中，有以下几个方面会获得大量的收获：

1．架构与模式

2．开源社区常见的一些惯用法

3．相关领域的结构与算法

总结一点是：学习开源，就尽可能在代码里找答案，而不是在代

码之外找答案，那些都是二手的，而且很可能是不准确的。

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

如何看待开源社（kaiyuanshe）

很早就因为罗聪翼的提问与邀请，关注了这个话题，却一直都没

有想好怎么回答。

我算是常年混迹于开源社区的一份子，这次的开源社从发起到成立，

我也算是深度参与者之一。“只缘身在此山中”，所以反而感到难以评

价。越是了解细节，就越是难以客观、全面地评价。

简单的挑一些关键词来讲吧：

摸索这个组织，从发起到成立，到各次的会议，有太多的讨论。各种意见，各种立场，各

种观点，各种设想，实际上没有一个人，清楚开源社究竟要做哪些事，怎么做，以及找什么

人来做？

举一个例子：我现在是开源社的文案小组的成员，主要参与起草

各种的文档。从最初的《成员合作备忘录》，约定成员的各种权利和

义务，到后来的各种规章、制度，都是大家参与讨论、起草、修改

的。最近正在讨论的，有入社申请表、FAQ、普通会员晋升核心会员

的制度等。

其他的各个小组，都存在同样的讨论、摸索的过程。我一方面从

中感受到了混乱，也感受到了未来的无限可能。身在其中，我很确信

的一点是：这种摸索，我也是参与者之一。如果希望开源社将来变得

更好，我责无旁贷。「混乱」，开源社的成员，有越来越多的趋势，我

们的一个微信群，几乎每天都会有新的成员加入。每周的例会，也会

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

有新成员自我介绍的环节。目前看来，开源社几乎是来者不拒的欢迎

各种申请者。

也由于这种源源不断的加入者，使得整个开源社，有太多想做的事

情，太多的计划与太多的可能。

各种参与者，如何协调？各种利益诉求，如何协调？各种提议与

建议，如何决策？各种贡献，如何衡量？

说实话，大多数问题，都还没有定论。各种组织能力与开会议事

的能力，也都有待提高。

「诉求」，当然，所有的参与者都是有所诉求的。基于自己的诉

求，对于整个开源社的诸多目标，也有种种赞同、旁观、不感冒的区

别。我并不完全了解其他人的诉求，仅仅谈谈自己的诉求。

我虽然是以个人身份加入的开源社，但毕竟我的职业身份是华为

的员工。我也希望能够对于自己的企业，带来某些益处。在我看来，

国内的大多数企业，对于开源的理解，都尚处在懵懵懂懂的状

态。“某个开源软件，开源类库，我们企业能不能用？”“我们企业能

不能参与到某个开源社区、开源项目中去？如何参与？”“作为企业，

应该如何确立自己的开源战略？”这些问题，很多企业不知道，也迫

切希望得到专家的咨询与指点。

如果开源社能够通过服务企业，进而对国内的开源环境有所改

善，这是我的主要诉求。至于开源社是否能够达成我的诉求，我尚且

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

无法肯定。我认识的很多朋友，也都处于观望的状态，我想只怕也是

出于这个原因。

最后，还得回到问题本身：“如何看待？”我想，也许可以拿一个

小故事来作为结论：“法拉第发现电磁感应之初，有人质问，这有什

么用处呢？法拉第的回答：一个新生的婴儿有什么用处呢？”同样

的，对于一个新生的社区“谈不上如何看待”。

原文发布于：2014 年 @ 知乎

两年后的今天，开源社已经做了很多有价值的工作，我也成为改组后

的理事会的理事，希望能够为国内的开源环境，做出更多的贡献。

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

成功的开源软件都有什么样的特点

一、萌芽阶段

1．解决实际问题，这是核心。不一定要特别创新，特别酷，当

然如果有的话是加分项。

2．定期发布，及时接受反馈，不断满足用户需求，形成稳定预

期。

二、成长阶段

1．出色的宣传手段、引导传播的能力。很多不错的开源项目因

为这一点不够，始终默默无闻。

2．足够好的协作机制。虽然开源社区通常有较为成熟的玩法，

但是做得不够好的项目比比皆是。

3．友好的参与引导。不断地吸引新人加入贡献（包括新手指

南、开发文档、Demo 等）。

三、成熟阶段

1．商业介入，获得资金支持。很多一开始选择了不太具备商业价

值的开源项目，会始终非常小众。

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

2．良好的社区氛围。老人有地位，新人有上升空间，公开透明

不内斗。

3．正确的方向感。这是长期繁荣的保障。以上这些，都依赖于

一个最重要的先决条件：足够强大、足够优秀的创始人+领导者！

这两天又思考了一下，发现开源软件与开源项目，还是有一些差

别的。通常来说：开源软件，主要是供最终用户使用，而开源项目，

则是一个更大的概念，可以做一个菱形图来说明：

在开源项目的基础上，可以创造一个好的开源生态圈，而基于开

源生态圈，会产生一个甚至多个不同的开源产品。这里说“开源产

品”，也就包含了“开源软件”与“开源硬件”。因此，深入思考的结果

就是——优秀的、成功的开源产品，依赖于良好的开源生态圈，而良

好的开源生态圈，严重依赖于最初开源项目的定位与类别。例如，依

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

赖于 Wordpress 的平台，诞生了一大批 Wordpress 的插件。依赖于

Eclipese 的平台，又诞生了一大批 Eclipse 的插件。

Firefox、Chrome 莫不如是。所以，一个能够让开发者参与扩展的平

台，是建立生态圈的重点之一。

再者，开发、调试、发布、获取、升级、评价这些扩展插件，是

否易懂，是否方便，是否快捷，也是一个生态圈，是否能够健康的重

要支撑特性。例如，Ruby 的 gem、Node.js 的 npm，就是极大地提升

了

Ruby 与 Node.js 的生态圈活力。所以，一个能够支持生态圈得以出现

的机制，一个能够辅助生态圈形成的工具，至关重要。

再深入地想一层，当我们开发一个软件，它应该具备哪些功能，

它的可扩展性该如何实现，则是考验最初创始人的架构能力的关键。

例如，UNIX/Linux 的核心思想——“一切皆文件”；再如，Rails 的核

心思想——“约定大于配置”以及"Rack 架构"所带来的活力。所以，优

秀的架构，能够从一开始，就为开源生态圈打下了良好的基础。

原文发布于：2014 年 11 月

Source Code + X

最近，有一位来自学术界朋友，找到了我们这个开源的圈子，因

为他正在做一个课题《开源项目知识共享影响机理》，打算做一轮访

谈。他所提出的大多数问题，都是围绕开源与知识共享展开的。我在

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

经过相当长的一段时间思考之后，却打算撇开那些问题，谈谈我的一

些思考。

最早的 Source Code，其实是非常学术性的，那些科学家们，研

究、发明并制造出了计算机，然后再编写计算机能够运行的代码。对

于科学家来说：代码与论文非常类似，都是学术成果，饱含知识。他

们应该，也必须被分享给学术界的其他专家。

所以，在非常早期的阶段：Source Code + 论文 = 知识分享

到了 1976 年 2 月 3 日，比尔盖茨发了一封著名的《写给电脑爱

好者的公开信》，高唱版权与利益。而且愤怒地将那些免费复制软件

的家伙，称之为：窃贼！盖茨的观点，可以说完全正当，甚至他的逻

辑也完全成立。如果无法保护商业软件的版权，那么整个软件行业都

不会出现，他们会永远停留在校园里，停留在学术阶段。

所以，在看到的软件利益之后：Source Code + 版权 = 利益

有一群黑客，他们崇尚自由，并且痛恨一切对于自由的限制，哪

怕是合理的，合法的限制。伟大的 Richard Stallman 站了出来，

在 1985

年发表了 GNU 宣言，并于 1989 年起草了 GPL，提出了 Copyleft 的

概念。

所以，在追求自由的黑客看来：Source Code + GPL = 自由

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

而在另一方面，“贪得无厌”的资本家们觉得版权法对于他们利益

的保护依然不够，他们需要借助专利的力量，不仅保证对手无法盗版

他们的软件，而且连仿制都将违法。从美国的软件专利的历史来看，

1992 年以后，美国的软件专利保护，一直在呈不断扩大的趋势。

所以，对于资本家来说：Source Code + 专利 = 受到更多保护的

利益

当然，这个世界上，中庸的人与团体，还是大多数。围绕着源代

码，大家也在探索，是不是能够建立某种利益的共同体，而且这个共

同体，并不会追求极端的自由，并不是仅仅为了共享知识，交流学

术，他们拿起了法律的武器，创作了很多种不同的 License，用于规

定

参与各方的权利与义务，不但能够与版权相容，甚至与专利都不产

生矛盾。（最早的 Open Source 这个名词，诞生于 1998 年）

所以，成千上万的人们，从五湖四海走来，团结在某一个

License 之下：

Source Code + License = Open Source

就像我不会批评比尔盖茨一样，没有对于版权的强调，就不会有

健康的软件行业。我也不会批评开源运动，没有足够好的利益协

调机制，仅仅靠理想与坚持，根本不会有现在这么多开源软件。

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

总体而言，我的态度是：自由软件值得尊重；软件版权应该遵

守；开源运动值得参与；专利说到底是个很糟糕的东西；而知识，蕴

含在任何能够被读到的源代码里。

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

三代开源社区的协作模式

一、研发工具与研发模式

据说，人之区别于禽兽，最大的特征在于利用，甚至发明工具。

在没有任何其他工具时，我们只能借助于自己的肢体，一旦有了工具

之后，我们的能力将会大大地增加。

但是，从另一个角度来看，工具也同时在限制我们的能力，甚至

限制了我们的行为模式与思维模式。有一句俗话说得好：“手里拿着

锤子，看见什么都像钉子。”

而在研发工具的领域，我们观察到另外一些有趣的现象：因为软

件研发工具的开发者，同时也是工具的使用者。因此，他们不仅仅会

受制于工具，也往往会由此被激发，开发出对自己而言更加趁手的工

具。开发者与使用者身份合二为一的现象，使得研发工具的发展，简

直可以用“日新月异”“层出不穷”，甚至用“争奇斗艳”来形容。

随着软件复杂性的不断增加，以及软件开发的参与者不断增多，

团队协作的辅助软件，也开始不断增加，随后我们发现：工具不仅仅

限制了个人的行为模式，更进一步限制了团队的协作模式。

软件研发企业的管理者，往往会有某种错觉，他们会认为：管理

就是定下制度、流程与规范，然后“下面的人”就会照此执行。因为有

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

人“听话”，有人“不听话”，所以才需要奖励与惩罚的制度，来帮助管

理者推行他的“规则”。他们一般都很喜欢看《执行力》这样的书。

在开源社区，事情变得有些不一样。虽说开源社区也有“领导

者”，甚至往往会有“精神领袖”，但他们并没有暴力手段，也没有经

济手段，甚至行政手段。因此，要协调一帮自由散漫的黑客，共同开

发高质量的开源软件，必须有更加高明的手段。

由于一切都是 Open 的，所以，不仅代码人人可见，开源社区的

协作模式也暴露在众目睽睽之下。从某种意义上来说：这促进了开源

社区的协作工具的开发，进而使得开源的研发协作模式，以远远超过

企业内部的演化速度飞速演化。

二、第一代开源协作模式

第一代开源协作模式，在早期几乎没有符合自身特殊需要的工

具，有什么用什么，因此最为常用的 email 被发展为 Maillist，成为整

个开发团队的协作核心工具，大多数操作系统内置的 diff/patch 工

具，

使得代码的交流以 email patch 为主。这些老牌的开源项目，从使用

RCS、CVS，到了后来也开始逐步引入 svn/git、bugzilla 这样的工

具，但是围绕 mailing list 开展协作的特征，则持久不变。

作为协作核心的 Maillist

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

一个开源社区，往往就是一个邮件列表，随着软件的日益复杂，

社区的不断扩大，邮件列表也会不断分化，通常会划分为：核心组、

开发组和用户组。开发组与用户组的邮件列表，随着软件的架构分化

为多个模块，还会进一步分解。

在邮件列表里，所有的用户都是平等的，在无法用工具保障流程

的情况下，社区逐渐发展出了一套严格的邮件礼仪和格式规范。不规

范的邮件，不会被理睬；不礼貌的家伙，甚至会被赶走。

邮件越来越多，即使分成多个邮件列表，依然太多。Archive 这

样的邮件归档、查阅的工具，就必须得有了。一封邮件，大家都来回

复，严格 re:的标题，组成了一个可供追溯的线索。

在邮件列表里，通常出现个人的名称，加上 Reported-By、

TestedBy、Acked-By 的标记，即是一种代表个人名义的认可，也是流

程规范的一部分，更是计算各人贡献的依据。

Bugzilla 应运而生

在邮件中，有一类话题是最活跃的，那就是 bug。但是，通过翻

找邮件查阅 bug 的最新的解决状况，是非常困难的。一个 bug，从提

出到最终解决，并被确认在哪一个版本中发布 fix，是一种稳定的状

态转化模式。一个专有的处理工具，势必应运而生。Bugzilla、trac 等

一批工具，就由此被创造出来了。

代码提交流程的规范化

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

开源社区，表面上非常的崇尚民主自由，但实际上却盛行精英主

义，甚至是个人独裁的。我们往往会给某个开源项目的创始人，冠以

“仁慈的独裁者”的头衔。虽然，是否仁慈，大家不得而知，但独裁确

实是显然的了。

最大的独裁，是代码的管理权。因为作为创始人与核心开发者，

他们往往以一己之力，贡献了绝大多数的代码，确定了项目最初的架

构与发展方向。他们不会容忍任何人随意地向代码库提交代码。

在邮件列表中，一个新来的家伙，从没人认识到能够独立地向代

码库提交代码，非得经历艰辛的历程不可。这样的历程，简单地说，

就是一次一次的 Code Review。被审核通过、合入代码库的 patch 越

多，一个人对于社区的贡献就越大，可信度也越高，身份地位也逐步

提高，然后，他也就可以去 Review 其他人的代码了。

总结：在简陋的工具条件下，发展出高效、严格的社区协作模式。

三、第二代开源协作模式

第二代开源协作模式，有两大特征：Web 化和集成化。随着

Web 技术的不断成熟，开源社区也开始创造一个又一个的 Web 开源

项目，其中 Web 化的项目管理工具，如雨后春笋般冒了出来。在

wikipedia 上，issue-tracking systems 列出了 55 个，project management

software 列出了 152 个，其中开源的也有 30+，open-source software

hosting 列出了

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

22 个，堪称蔚为壮观。

这类平台又可以分为两大类：基于开源的项目管理工具或 issue

tracking 工具，自建平台，以 JIRA、DotProject、Redmine 为代表；基

于免费开源托管平台，以 SourceForge、Google、LaunchPad 为代表。

第二代的开源项目管理工具，可以说，主要是在向企业内的开发管理

学习。文档、流程、角色、权限、统计报表等功能都开始出现了。有

些开源项目，也在用这些东西。

以 SourceForge 与 Google Code 为代表的开源托管平台免除了开源

项目搭建自己的官方网站，管理工具，代码仓库之类的繁琐事务，大

大促进了开源项目的发展。不过，由于平台的功能总是受限的，因此

自建门户，自组工具的开源项目依然层出不穷。

issue & milestone

在第二代开源协作模式日渐成熟的过程中，另一股潮流也正方兴

未艾：敏捷软件开发。其中，最为深入人心的概念之一，就是每个迭

代，完成一批 User Story。

在开源社区，这个概念被进一步演绎：无论是 bug 和 feature，都

被统称为 issue。这些 issue 被分到不同的 milestone（版本），即使最

后有可能延期，milestone 也会定义一个预期完成时间。

这是好事，还是坏事？其实很难评价，因为从开源的原始教义而

言：所有的贡献，都是自愿、随机、不可预期的。为自然生长的软

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

件，规定里程碑，本来就显得荒谬。但是，从另一方面而言，我们可

以引用另一个中国人过马路的例子：“不管红绿灯，凑够一堆人就过

马路”，开源软件往往也是“不管里程碑，稳定一堆特性和 bugfix，就

发布一个版本”。

如果在开源软件很少，更别提形成开源生态圈的情况下，这种随意的

做法还是可行的。但是在大量软件，相互依赖的情况下，一个开源项

目要赢得其他协作项目的信赖与协作，必须给出稳定的规划，以便相

互配合。

这种规范，也是被逼出来的。

服务平台化

虽然黑客们喜欢写程序，但是要写的程序实在太多了，能够不重

复造轮子，有现成的好工具可以直接拿来用，也是件好事。如果可以

打开一个网站，注册一个用户，创建一个新的项目，剩下的事情自有

平台帮忙打理，那么大家都可以愉快、专心地写自己的代码了。

平台在逐步进化，因而能够帮助开源项目，打理越来越多的事

务。通常主流的开源项目托管平台，都能够完成：

在线代码浏览，并能够支持不同的配置库。

需求管理、Bug 管理，通常合并为 Issue tracking。

版本与里程碑管理。

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

文档编写与管理，以 Wiki 的形式为主。

更进一步的，还有能够完成：简单的自定义工作流、文件夹与静

态资源管理、输出各种统计报表，甚至提供论坛、搜索、邮件列表以

及各种排行榜等。在此之前，一个开源项目，是一个社区。到了大平

台的时代，整个平台，构成了一个更大的社区。

总结：以 Web 形式提供的集成化开源项目托管平台，标志着开源项

目的协作模式，进入成熟期。

四、第三代开源协作模式

到了 MySpace、Facebook 与 Twitter 这样的 SNS 网站的兴起，开

源项目的协作模式受到 SNS 的启发，也随之进入了第三代，以 Social

Coding 为核心的开发协作模式，这样的模式在以 Github 为代表的网

站上，体现地最为充分，众多的模仿者也层出不穷。过去的开源项目

与托管平台，都是以项目为中心来打造，而 Github 则是围绕着参与

开源的人来打造。首先满足的不是项目的需求，而是个人的需求，由

于对

人的黏性大大增加，也使得 Github 成为近年来最具吸引力的开发社

区。

围绕着 Github，一大批周边扩展服务被建立起来，构成了一个更

加有活力的生态圈。而程序员们，不仅在 Github 上参与开源项目，

更在 Github 上结交朋友，分享经验，增进能力。甚至这样的协作模

式，还拓展到了编程领域之外，成为开放式协作的流行模式。

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

激励机制

第三代开源协作模式，以 Github 为代表，以 Social Coding 为精

髓，这一代模式想要解决的问题，是激励机制的问题。第一代开源协

作，虽然创造了一批大大有名的项目，但事实上却是一个非常小圈子

的事业。即使是最为成功的 Linux 内核开发，也不过 1000~2000 人。

一旦人多事杂，就会出现管理混乱的现象。

第二代开源协作，虽然借鉴了很多企业界的规范管理经验，但是

在事实上，却是不适应开源软件的风格的。举一个例子：在 Redmine

中存在的角色、权限、工作流之类的东西，实际开源项目使用的，却

非常少。

第三代开源协作，借鉴了社交网络中的各种数值化模型、关注者

数量、Star 数量、Fork 数量、Issue 数量、Pull Request 数量，都在显

要位置标示出来，对于开发者形成正向激励，还有很多的统计图表，

形象地展示了项目的活跃程度。

开源社区，原本就有非常深厚的，统计补丁数计算贡献度的传

统，这一点在 Github 被发扬光大，可以说是优秀的继承与创新。

基于 fork/pull request 的协作机制

在 Github，一键就能够 fork 自己的分支，然后可以跟原有的分支

毫无关联，也可以非常方便地提交 pull request，这就带来了更加频繁

的分裂，使得分裂常态化了。

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

原来的开源社区，开发者修改了代码，希望能够贡献给社区，需

要穿越种种障碍，如果社区不接受，最后开发者只能逼不得已，自己

开一个新的分支，变成一个新的项目。在分裂是异常的状态下，分裂

是罪恶的，是不应该的，是会带来阵痛的。当分裂变得常态化，pull

request 也变得常态化，分分合合，以每天 N 次的速度发生。恰恰因

为如此，它不再是一种罪恶，而是一种健康的、向上的、以更快速度

进步的模式。大家不再是在一个版本下，各自贡献，而是在各自的版

本下，独立发展，想分就分，想合就合。

Pull request，从一个代码合并的方式变成了开发者之间主要的交

流方式，他们发现，最好的交流，正是通过源代码来交流，一切的讲

道理都不如用源代码来讲道理。这恰恰是程序员们最习惯，也最喜欢

的一种交流方式。

围绕 Github 出现的扩展服务

较之上一代的平台，Github 提供了优秀的开放扩展机制：

OAuth、API、SDK、WebHooks、ServiceHooks 等，使得围绕

Github，扩展各种满足项目特定需要的服务，变得非常容易。

这就是从上一代平台的开源大社区，进化为“围绕 Github 的开源

生态圈”。

到目前为止，Github 一共支持超过 170 个不同的扩展服务，其中

较为热门的服务有：

与其他项目管理工具集成（Bugzilla、Asana、Basecamp、

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

Redmine、JIRA、ZohoProject）。与持续集成服务集成（Travis、

Bamboo、CircleCI）。

与消息通知服务集成（Amazon SNS、Email、IRC、Jabber）。

与 DevOps 服务集成（AWS OpsWorks、DeployHQ）。

Github 开放平台与 API，基于 Github OAuth API，其他网站可以

支持开发者用自己 Github 账号登录，并使用一些有趣的服务。

Cloud IDE：用 Github 账号登录，直接在浏览器里打开一个

IDE，编辑自己在 Github 上的开源代码。

Resume Service：根据开发者在 Github 上的各种社交行为与开源

项目贡献度，自动生成格式化的简历。

这些扩展服务，极大地丰富了开源生态圈的内涵。

总结：社区天生就应该是社交化的，Social Coding 与开源社区，简直

就是天作之和。

五、开源协作模式的新探索

Git：作为标配

目前看来，Git 作为分布式配置库的王者地位，已经不可动摇

了。能够初步总结的原因，至少有三个。

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

Git 与 Github 互相促进，作为全球最大也最流行的开源社区，它

的标配是 Git。这也导致越来越多的开源项目，选择 Git 作为标

配。众人拾材火焰高，越是参与开发的人不断涌入，越是帮助

Git 发展得更快。这是一个赢家通吃的世界。

开源生态圈的出现，使得围绕 Git、Github 发展出一大批相关的开

源项目、开源工具以及次级社区。这一现象在 docker 横空出世

之后，再一次得到展现。

Code Review：必不可少

开源社区，一直有非常悠久的 CodeReview 的历史，哪怕在最早

的 mail & patch 的时代，Review 也是开源协作的头等大事。仅仅梳理

Review 的历程，也可以看到其中工具与流程的发展。

最初是邮件 review，然后是在集成平台上内置 review 功能，或者

提供更强大的 review 插件。到 Github 创新的提出 pull request，则是

一种更加方便有效的 review 模式。

与此同时，独立于集成平台的专门的 code review 工具也开始发展

起来：Review Board、Google Gerrit、Facebook Phabricator 是其中重要

的几个代表。

Workflow：百花齐放

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

在 Git 逐步流行之后，大家发现基于 Git 可以选择的“玩法”实在

是太多了。从最初写下一行代码，到最终出现在项目发布的版本之

中，其间可以有无数的“路径”。

在 git-scm.com 官方教程《ProGit》里，提及了 3 种：集中式工作

流、集成管理员工作流以及司令官与副官工作流。

在蒋鑫的《Git 权威指南》里，又提及基于 TopGit、基于

submodule、基于 subtree、基于 repo、基于 gerrit、以及 Git 与 SVN

配合使用的不同工作模型。

再后来：GitFlow、Github 的 Pull Request，以及基于 Github 的

Github Flow 等工作模式，堪称百花齐放。

为什么会出来这么多 workflow？因为团队与项目的差别实在太大

了。现在到我们简直无法想象：那些在各种情况下都坚持使用 SVN

都开发者是怎么熬过来的？

当然，从另一方面来说：选择太多，也会带来另一种烦恼..……

CI、CD、DevOps

从 Everything as Code 到 Everything Automation，是另一个越来越

明显的趋势。前两天，我从机场出来，正好看到两个并列的广告牌，

一个广告的大意是：“UPS 助您打通全球供应链”，另一个则是“中国

银行助您打通全球供应链”。这真的很有意思，看来在各行各业，大

家都开始在关注整个生命周期的各个环节之间的打通。

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

只是，在软件领域，我们会感觉到这是一种回归。毕竟，最初的

软件开发都是很简单的。在一台计算机上，自己写程序，自己编译，

自己调试、运行，最后发布。既不用依赖他人，更不用等待什么流程。

随着项目越来越复杂，参与的人越来越多，我们的软件不能仅仅

运行在自己的机器上，或者需要部署到服务器上，或者需要发布到某

种平台上。在协作者众多的情况下，如何分工合作？在开发者水平参

差不齐的情况下，如何保证质量？在分工、协作、流程与质量保证的

要求之下，如何提高效率？

这些都是 DevOps 致力于解决的问题，也是 DevOps 不断得以发

展的原动力。

总结：开源社区，始终在进步，Github 代表的也只是“一代”而已，

新的一代协作模式还会被创造出来的。

六、暗线：工具、习俗背后的逻辑

过去是如何？未来又会怎样？想要回答这类问题，其实需要更加

深入的思考：“开源社区的协作模式，为何会变？变化背后的逻辑是

什么？”

开源社区研发工具的两大目标：降低门槛，提高效率

开源社区与普通的软件开发最大的不同，就是参与者多多益善。

在《大教堂与集市》中，Eric Steven Raymond 总结到：“如果开发者

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

协调者有至少一个像 Internet 这样好的沟通媒介，并且知道如何不靠

强制

来领导，那么多人合作必然强于单兵作战”，这简直就是绝妙的预

言。虽然当年的 ESR 也许并未预测到，基于 Internet 会出现那么多辅

助开源的相关工具（他们当时还只有邮件列表）。所以，开源社区一

直在致力于两个看上去相反的目标：“吸引尽可能多的人，以尽可能

简单、便捷的方式，参与到开源中来”“在人多得超乎想象的情况下，

依然能够保持，甚至不断提高效率”。

如何计算参与者的贡献

开源社区不会给参与者发工资，因此激励是一个大问题。公平、

公开、公正地计算所有参与者的贡献，以所有人都能够接受的形式，

计算并公布各种排行榜，可以说是开源社区特有的“刚性需求”，因

此，SNS 与开源社区的结合成为必然。以后，面向开源协作的大数据

分析也一定会出现。

如何激励、吸引、回报参与者

计算参与者的贡献，仅仅是公平激励的基础。让激励变得有趣，

变得有价值，变得有意义，则是吸引与回报参与者的不二法门。因

此，游戏化的思路，会被越来越多的引入到开源社区中来。

如何保障项目质量

开源项目保障项目质量的最大利器，是引入数量众多都热心测试

者。但是，仅仅有人愿意测试，主动、积极地帮助测试，已经越来越

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

不够了。随着项目越来越复杂，开源项目必须逐步走出仅仅依赖肉

眼、依赖人多＋运气的质量保障模式。

自动化测试以及更加规范的 Review 流程，则是必然出现，而且

将越来越重要的环节之一。

如何协调一致的工作自由与规范，计划与变化，兴趣与责任，经常会

在社区里，成为争论的热点话题。虽然在《大教堂与集市》中，ESR

极力鼓吹“礼物文化远远胜过交换经济”，但是，“在一个庞大的社

区，各种各样的事务都需要有人去完成，而且还不能漫无章法。”

因此："某种调节手段、协调者与协调机制、甚至是看不见的手"

之类的东西，会慢慢地回到社区。

如何在社区里平等、高效地协商

目前来说，依然只能是线上讨论+线下开会。虽然很多开源社

区，开始学习《罗伯特议事规则》这样的开会圣经。但是，开会依然

是最令程序员感到苦恼的事情。在这方面，将来会不会出现更好的辅

助工具，这方面很值得期待。

结束语

唯有变化，是不变的。开源协作模式，同样如此。惟愿我们，能

够成为推起其前进的力量之一。

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

聊聊 Github 的方法与哲学

开源已经是一场革命，但是在开源的发展历史上，其实依然在不

断地发展，甚至革命。简单地回顾一下：

最早的开源，仅仅是把自己的源代码开放出来，或者让别人用磁

带复制带走，或者放在 Server 上供人下载。

再后来，关于这个项目的代码与功能，就浮现出来了两个问题：

代码大家都能改，如何整理与汇总各自的工作成果？功能大家都有想

法，最后应该做成什么样？

于是，源代码版本管理工具与各种在线讨论的方式，开始了一轮

又一轮的演进。具体的项目就不再一一列举，但是其中最大的一次创

新，就是从集中式版本管理走向了分布式版本管理。如果说 Github

有自己的哲学，它的来源，首先是分布式开发的理念。

分布式开发与分布式版本管理：没有一个核心的版本库，意味着

没有任何一个人、任何一个组织是核心，每个人都可以在自己的机器

上保留全部的版本树，并且不断发展自己的版本。一个人的代码，既

可以贡献给 A，也可以贡献给 B，一切自由。

随着 Linux 开发的哲学，被逐步地传播开来，才有了 Github 的出

现。最初的 Github 的最大的贡献，是将这种无中心，多分支的开发

模式，Web 化、常态化了。一键就能够 fork 自己的分支，然后可以跟

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

原有的分支毫无关联，也可以非常方便地提交 pull request，这就带来

了更加频繁的分裂，使得分裂常态化了。

原来的开源社区，我改了代码，希望能够贡献给社区，需要穿越

种种障碍，如果社区不接受，最后我只能逼不得已，自己开一个新的

分支，变成一个新的项目。在分裂是异常的状态下，分裂是罪恶的，

是不应该的，是会带来阵痛的。当分裂变得常态化，pull request 也变

得常态化，分分合合，以每天 N 次的速度发生，恰恰因为如此，它

不再是一种罪恶，而是一种健康的、向上的、以更快速度进步的模

式。大家不再是在一个版本下，各自贡献，而是在各自的版本下，独

立发展，想分就分，想合就合。

这背后折射出的哲学，可以这样总结：如果将分裂视为罪恶，而

力图用各种方法去阻止，总会碰到各种各样的新的困难。如果反其道

而行之，通过技术手段尽可能地方便分裂与合并，这反而是满足了真

正的需求。（阻止分裂，其实是在压抑开发过程中存在的真实需求）

所以，尽力满足真实的需求，才有可能获得成功。

随着这样的模式，变得常态化，然后 Github 才被称为一个社

区， fork/pull request 也从一种开发行为变成了一种社交行为。于

是，程序员们发现，最好的交流，正是通过源代码来交流，一切的讲

道理都不如用源代码来讲道理。这恰恰是程序员们最习惯，也最喜欢

的一种交

流方式。这当然也是因为满足了真实的需求。甚至我们可以说，

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

Github 创造了真实的需求。随后的事情是顺理成章的，程序员们泡

在 Github 上，自然想在

Github 上做所有的事情，这不必再过多分析了。

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

降低门槛与质量控制

从 Linus 抨击 Github 说起：托瓦兹抨击 GitHub：某些功能很垃圾

开源，是一个很神奇的事情。Linus 在开发 Linux 的时候，受到

的最大的指责就是质量控制不力。但是，Linus 对此并不太在乎，还

发

明了一个 Linus 定理：“足够多的眼睛，就可让所有问题浮现”（given

enough eyeballs, all bugs are shallow）。

开源的精神本质，可以认为是一场不收门票的盛宴，任何人都有

机会参与进来。当然，质量因此而下降，也是必须解决的问题。

从集中式代码管理到分布式代码管理，是再一次的降低门槛。开

发者不依赖于主库，就可以创建自己的分支。我的代码就算原来项目

的人不接受，我也可以继续搞下去。分布式的核心，是去中心化。去

中心化的本质是否定权威。不过，去中心化导致的，是质量控制更加

困难。

当然，Github 基于 Git，将去中心化几乎做到了极致；将参与开

源的门槛，几乎拉到了最低点。从 Linus 这位发起了两次降低门槛运

动的“革命老人”来说，他对于第三次降低门槛的行为，受不了了。

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

很多时候，我们都会在历史上看到这样的现象：革命的旗手停下

来了，不再继续前进了。他喊道：够了，再这样下去，就是错的了。

但是，后来者依然再继续前进，并且走得更远。

回到技术问题的探讨：为了保障质量，回到权威主导的中心化模

式，当然是一个办法。但是，有没有更好的办法？

topgit，gitflow，是针对 Git 的功能扩展。

hubflow，是基于 Github 的 gitflow。

repo+gerrit，是不依赖 Github 的协作模式创新。

http://gerrithub.io，是基于 Github 的 gerrit。

更多的工具，正在层出不穷，更多的创新，还在源源不断地涌

现。

我想：向前看，才是合理的方向。

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

黑客的胜利——读《增长黑客》有感

增长黑客

这本书在写的时候，我就知晓，只是一直没有去看。作者是我在

盛大创新院的前同事，所以在出版之后也很高兴收到了寄来的赠书。

简单翻阅之后，就大为喜欢。只不过，我与大多数人喜欢的理由，大

不相同：

也许 90%的人，是因为这本书在讨论“增长”，而我却是因为这本书

在讨论“黑客”。也许 90%的人，会非常喜欢这本书干货满满的“案

例”。而我却很遗憾，这本书对于“术”讲得太多，“道”却讲得太少!

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

什么道？当然是黑客之道！

黑客文化的起源可以追溯到 1961 年，那一年麻省理工学院

（MIT）终于得到了第一台 PDP-1 计算机。学院技术模型铁路俱乐

部（Tech Model Railroad Club，TMRC）的信号动力委员会

（Signals and Power Committee，S&P）把它作为最时髦的科技玩

具，并由此产生了许多程序设计工具、术语和整个文化氛围——

这些，直到今日我们仍然依稀可辨。史蒂文·利维（Steven

Levy）在《黑客》（Hackers）的第一部分中详细地记录了这段岁

月。

——《黑客道简史》E.S.R

也许很多人会认为，黑客就是一帮搞计算机的高手。但事实上，

E.S.R 在另外一篇文章里，有很清楚的表述：“黑客的思维方式并不

仅仅局限在软件黑客的文化圈内。也有人用黑客态度对待其他事

情，如电子和音乐方面——其实你可以在任何最高级别的科学和艺

术活动中发现它的身影。软件黑客对这些领域的践行者尊重有加，

并把他们也称作黑客——有人宣称黑客天性是绝对独立于他们工作

的特定领域的。”

——《如何成为一名黑客》

那么，黑客是一群什么样的人呢

1. 渴望了解世界，更擅长“深入”地了解世界

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

为了能够了解世界，他们愿意想尽一切办法，甚至不惜做一些出

格的事情。小时候，他们会拆玩具，拆闹钟，拆掉各种玩意。长大以

后，他们会渴望阅读源代码，并且痛恨一切闭源的行为。

所以，如果有一扇门是关着的，那对黑客就是一种挑战。而如果这扇

门上了锁，那简直就是对黑客的侮辱。

2. 痛恨无聊、乏味、低效，鄙视蛮干与蠢干

这个世界上，有各种各样的蠢货，而最糟糕的那种：就是强迫他

人和自己一样愚蠢，并保持愚蠢的家伙。

在黑客的文化中，干成一件事，并没有太了不起。重要的是，手法必

须巧妙，甚至能够给人带来观赏的乐趣，这样的成就，才能被称之为

“Hack”。

3. 死理性派

大多数黑客都是典型的理工男。当然，现在也许女黑客也有一些

了。这些人，最重要的特征之一，就是非常理性，甚至较真。哪怕是

在讨论那种“明显是幻想域的问题”，他们也会以严谨的形式，罗列出

前后逻辑一致的一大堆证据。

对于这种死理性派来说：数据和逻辑，是他们最喜欢的武器。

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

推荐一部电影

我是谁：没有绝对安全的系统

这是我近年来看到的，最具有可信度的黑客电影。其中有一段情

节，是那群人通过翻找垃圾堆里的明信片，然后找到了一个爱猫的目

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

标对象的邮箱。然后再发一封萌猫的邮件包含一个钓鱼网站，再由此

而植入木马……

这背后的逻辑，是“基于对人性的深入了解，进而找到了一个系

统的漏洞”。这恰恰是最为典型的黑客的思维模式。只不过，应用于

社会学的领域了。

在这部电影中，这种手法被称为“Social Engineering":

“人不能总藏在他的计算机后面，最大的安全漏洞并不是存在于什

么程序或者服务器内，人类才是最大的安全漏洞。”

“所有黑客手段中最有效的、最伟大的幻想艺术——社交工程学。”

那么，这些与增长黑客有什么关系

增长黑客，其实就是一群黑客，接到了一个“增长类”的任务，然

后漂亮地“hacked”而已。

在书中的很多例子，都有这样一些要素：“数据驱动、用户心

理、巧妙的手法、惊人的成效”。

如果我们阅读这本书，就是去学习这一堆一堆的案例，那简直就

是买椟还珠，难免会有邯郸学步的危险。更加应该探寻的，是为何他

们会干得这么漂亮？以及，如何才能在今后千变万化的市场中，不断

地创造新的增长奇迹？成为一家“黑客友好型”的公司，甚至成为一家

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

“以黑客文化为主导”的公司，是唯一的方法。难以想象，我们可以给

一个家伙，冠

上“Growth Hacker”的头衔，他就自然会为公司带来惊人的增长。如果

这个公司，根本没有供“黑客文化生长的土壤”，我们只会看到一个又

一个“Copy To China”的愚蠢案例。

如何建立“黑客型组织”

1. 规定目标，不规定动作

我们会设立目标，甚至设立看起来完全不可能的目标。但是：想

要完成这样的“不可能的任务”，就不能规定任何“标准动作”——当

然，违法的除外。

2. 限制规模，不限制角色

从来没有听说过，上下共有 6~8 个层级，等级森严的大型组织，

会具有黑客型的气质。小团队，扁平化，是孕育黑客文化的关键土

壤。在这种团队里，每个人都可能会承担一种以上的职责，甚至在必

要时，每个人都能够补上他人的缺口。

3. 崇尚实力，不崇尚权威

没有谁肯定是对的，除非事实证明他是对的。没有谁高人一等，

除非他确实强悍到近乎无所不能。

异步社区会员 /db 冷锋(18823840827) 专享尊重版权

正如成为“黑客”的关键要素之一，是得到其他“黑客”的承认。一个黑

客型组织的关键要素也包括：每个人的能力，都能够得到其他成员的

认可。

结束语：以黑客的方式来创业

这段时间，越来越流行的一个词，叫做“精益创业”，在我看来：

所谓“精益”，无非是死理性派的黑客们，在创业时的必然选择罢了。

当然，这个话题又太大了，就此打住……

最后，胜利属于黑客